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(54) Abstract Title 

Smart card with travel and/or business partner scheme applications 

(57) A smart card comprises a common application, e.g. a cardholder identification application 404, 406, and 
at least one second application concerned with a travel related and/or business partnering scheme application. 
Preferably the second application is either a payment system 408, with stored account number and expiry date 
(Figure 6). an airline flight and ticket application 410, a hotel reservation application 412, or a hire car 
application 414 having details of the card holder's preferred car (Rgure 8). Preferably all of the business 
partners Involved in the partnering scheme have access to the common application, containing the card holder 
name and address (Figure 5), but each business partner can only utilise the second application with which it is 
associated, e.g. a hotel chain may only access the hotel reservation application. Other cardholder details may 
also be stored on the smart card, e.g. insurance, biometrics data, driving licence, passport, and social security. 
A business partnering organization (Figure 10), having a partnering organisation server and a transmission 
network (19, Figure 10), for use with the smart card are also dislosed. 
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At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 

This print takes account of replacement documents submitted after the date of filing to enable the application to comply 
with the formal requirements of the Patents Rules 1995 
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2333630 

METHODS AND APPARATUS FOR A TRAVEL-RELATED 
MULTI-FUNCTION SMARTCARD 



inventors : William Hohle and Frederic Petit 
Tyr^nicai Field 

5 The present invention relates generally to the use of integrated circuit cards, or 

"smancards " Tor commercial transactions and, more particularly, to methods and 
apparatus for conveniently storing, retrieving, and updating data related to a cardholder's 
travel information in the context of a distributed transaction system. 

fj^i ^koroun d Art nnd Technical Problems 

1 0 Despite advances in infomiation lecluiology and process streamlining vsnih respect 

to travel arrangements, the modem traveler is often subjected to unnecessary delays, 
petty inconveniences, and oppressive paperwork. These travel burdens are most evident 
in the airline, hotel, and rental car industries, where arranging and paying for services and 
accommodations can involve significant time delays due to miscommunication, poor 

1 5 record-keeping, and a host of other administrative inefficiencies. 

Smartcard technology, as described below, has had limited success in addressing 
some of these problems. The tenn "smancard" refers generally to wallet-sized or smaller 
cards incorporating a microprocessor or microcontroller to store and manage data within 
the card. More complex than magnetic-stripe and stored-value cards, smancards are 

20 characterized by sophisticated memory management and security features. A typical 
smartcard includes a microcontroller embedded within the card plastic which is 
electrically connected to an array of external contacts provided on the card exterior. A 
smartcard microcontroller generally includes an electrically-erasable and programmable 
read only memory (EEPROM) for storing user data, random access memory (RAM) for 

25 scratch storage, and read only memory (ROM) for storing the card operating system. 
Relatively simple microcontrollers are adequate to control these functions. Tlius, it is not 
unusual for smancards to utilize 8-bit, 5 MHZ microcontrollers with about 8K of 
EEPROM memory (for example, the Motorola 6805 or Intel 8051 microcontrollers). 
A number of standards have been developed to address general aspects of 

30 integrated circuit cards, e.g.: ISO 7816-1. Part 1: Physical characteristics (1987); ISO 



7816-2. Port 2: Dimensions and location of the contacts (1988); ISO 7816-3. Part 3: 
Electronic signals and transmission protocols (1 989, Amd. 1 1 992. Amd. 2 1 994); ISO 
7816-4, Port 4: Inter-industry commands for interchange (1995); ISO 7816-5. Port 5: 
Numbering system and registration procedure for application identifiers (1 994. Amd. 1 

5 1 995); ISO/IEC DIS 7816-6. Inier-industry data elements (1995); ISO/lEC WD 781 6-7. 
Part 7: Enhanced inter-industry commands (1995); and ISO/IEC WD 7816-8. Part 8: 
Inter-industry security architecture (1995). These standards arc hereby incorporated by 
reference. Furthermore, general information regarding magnetic stripe cards and chip 
cards can be found in a number of standard texts, e.g.. Zoreda & Oton, Smart Cards 

1 0 (1 994), and Rankl & EfRng. Smart Card Handbook ( 1 997), the contents of which are 
hereby incorporated by reference. 

Various attempts have been made to alleviate travel-related inconveniences through 
the use of smartcard technology. In 1995. for example, the U.S. airline industry led an 
effort to reduce ticket distribution cosu by developing standards for "ticketless travel." 

1 5 Soon thereafter, a joint conference of 1 ATA and ATA adopted a set of specifications 
entitled Specifications for Airline Industry Integrated Circuit Cards (hereinafter, "lATA 
standard"). Similarly, in the field of financial payment systems, a standard has been 
developed entitled EMV Version 2.0. Integrated Circuit Card Specifications for Payment 
Systems. Parts 1-3 (1995). Both of these specifications arc hereby incorporated by 

20 reference. 

Notwithstanding widespread promulgation of these standards, smartcard efforts 
lend to remain fragmented, and the resultant benefit to consumers - particularly 
consumers who travel -- has been quite minimal. One recent study estimates that 
approximately nine million smartcards were issued in the transportation and travel 
25 industry in 1 996. yet, for the most part, these cards remain incompatible; that is, due to 
differing file structures and/or communication protocols employed, card data typically 
can not easily be shared across applications or between industry participants. 

Systems and methods arc therefore needed in order to overcome these and other 
shortcomings in the prior art. 
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^^itt ^nfarv of the Invention 

The present invention provides methods and apparatus for a smartcard system 
which securely and conveniently integrates important travel-related applications, thereby 
5 overcoming the limitations of the prior art. In accordance with one aspect of the present 
invention, a smartcard system comprises a cardholder identificalion application and 
various additional applications useful in particular travel coniexts; for example, airline, 
hotel, rental car, and paymeni-rclated applications. In accordance with another aspect of 
the present invention, a smancard system further comprises space and security features 
10 within specific applications which provide partnering organizations the ability to 
construct custom and secure file structures. 

Pr iff Pescription of the Drnwing Figures 

The present invention will hereinafter be described in conjunction with the 
appended drawing figures, wherein like numerals denote like elements, and: 
1 5 Figure 1 illustrates an exemplary smartcard apparatus; 

Figure 2 is a schematic diagram of an exemplary smartcard integrated circuit, 
showing various functional blocks; 

Figure 3 is an examplary diagram of files and directories arranged in a typical tree 
structure; 

20 Figure 4 sets forth an exemplary database structure in accordance with a preferred 

embodiment of the present invention; 

Figure 5 sets forth a preferred cardholder ID data structure in accordance with the 
present invention; 

Figure 6 sets forth a preferred payment system data structure in accordance with 
25 the present invention; 

Figure 7 sets forth a preferred airline data structure in accordance with the present 
invention; 

Figure 8 sets forth a preferred rental car data structure in accordance with the 
present invention; 

30 Figure 9 sets forth a preferred hotel system data structure in accordance wth the 

present invention; and 



Figure U) ilhisiraies nn exemplary disiribuied iransaciion system useful in 
practicing the present invention. 

n^tailcd Pcscripfioii of l^refcrrcd Ex cmplan' Embodiments 
5 Referring now to Figures 1 and 2. an exemplary smancard system suitable for 

practicing the present invention will now be described. A smartcard 100 generally 
comprises a card body 102 having a communication region 104 for providing contact or 
non-contact communication between an exiemal device (e.g., a card reader) and an 
integrated circuit 110 encapsulated within card body 102. Communication region 104 

10 preferably comprises six conductive pads 106 whose placement and size conform to 
IS07816-2. More particularly, a communication region 104 in conformance with ISO- 
7816-2 preferably comprises VCC contact 106(a) (power supply), RST contact 106(b) 
(reset), CLK contact 1 06(c) (external clock), GND Contact 1 06(d) (ground), VPP contact 
106(e) (programming voltage), and I/O contact 106(0 (data line). 

1 5 VCC 1 06(a) suitably provides power to IC 11 0 (typically 5.0 V +A 1 0%). CLK 

106(c) is suitably used to provide an external clock source which acts as a data 
transmission reference. RST 106(b) is suitably used to transmit a reset signal to IC 1 10 
during the booting sequence. VPP contact 106(e) may be used for programming of 
EEPROM 212 in IC 1 10. As is known in the art, however, this conlacl is generally not 

20 used since modern ICs typically incorporate a charge pump suitable for EEPROM 
programming which takes its power from the supply voltage (VCC 106(a)). 1/0 106(f) 
suitably provides a line for serial data communication with an external device, and GND 
1 06(d) is suitably used to provide a ground reference. Encapsulated integrated circuit 
110 is configured to communicate electrically with contacts 106 via any number of 

25 known packaging techniques, including, for example, ihermosonically-bonded gold 
v^res, tape automated bonding (TAB), and the like. 

While an exemplary smartcard is discussed above in the context of a plurality of 
exiemal contacts, it will be appreciated that coniactless cards may also be utilized to 
practice this invention. That is, non-contact communication methods may be employed 

30 using such techniques as capaciiive coupling, inductive coupling, and the like. As is 
known in the art, capacitive coupling involves incorporating capaciiive plates into the 
card body such that data transfer with a card reader is provided through symmetric pairs 
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of coupled surfnccs. wherein capaciiancc values are typically 10-50 picofarads, and the 
working range is typically less than one millimeter. Inductive coupling employs coupling 
elements, or conductive loops, disposed in a weakly.coupled transformer configuration 
employing phase, frequency, or amplitude modulation. In this regard, it will be 
5 appreciated that the location of communication region 1 04 disposed on or within card 
100 may vary depending on card configuration. For additional information regarding 
non-contact techniques, sec, for example, contactless card standards ISO/IEC 10536 and 
ISO/lEC 14443, which are hereby incorporated by reference. 

Smartcard body 102 is preferably manufactured from a sufficiently rigid material 

10 which is resistant to various environmental factors, e.g., physical deterioration, thennal 
extremes, and ESD (electrostatic discharge). Materials suitable in the context of the 
present invention include, for example, PVC (polyvinyl chloride), ABS (acrylonilrilc- 
butadiene-styrol), PET (polyethylene terephthalate), or the like. In a preferred 
embodiment, chip card 100 conforms to the mechanical requirements set forth in ISO 

15 7810, 7S 13, and 7816. Body 102 may comprise a variety of shapes, for example, the 
rectangular ID-1, lD-00, or lD-000 dimensions set forth in ISO-7810. In a preferred 
embodiment, body 102 is roughly the size and shape of a common credit card and 
substantially conforms to the lD-1 specification. 

Referring now to Figure 2, IC 110 preferably comprises regions for Random 

20 Access Memory (RAM) 2 1 6, Read-Only Memory (ROM) 214, Central Processing Unit 
(CPU) 202: data bus 210, Input/Output (1/0) 208 and Electrically-Erasable and 
Programmable Read Only Memor}' (EEPROM) 212. 

RAM 216 comprises volatile memory which is used by the card primarily for 
scratch memory, e.g., to store intermediate calculation results and data encryption 

25 processes. RAM 2 1 6 preferably comprises at least 256 bytes. 

EEPROM 212 provides a non-volatile memory region which is erasable and 
rewritable electrically, and which is used to store, inter alia, user data, system data and 
application files. In the context of the present invention. EEPROM 212 is suitably used 
to store a plurality of files related to cardholder travel information (discussed in greater 

30 detail below in conjunction vAxh Figure 3). EEPROM 2 1 2 preferably comprises at least 
8K bytes. 
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In a prefeired embodimem. CPU 202 implements the instruction set stored in ROM 
202, handles memory management (i.e.. RAM 216 and EEPROM 212). and coordinates 
input/output activities (i.e.. 1/0 208). 

ROM 214 preferably contains, or is "masked" with, the smart card operating 
5 system (SCOS). Thai is, the SCOS is preferably implemented as hard-wired logic in 
ROM 214 using standard mask design and semiconductor processing methods well 
known in the an (e.g.. photolithography, difftision, oxidation, ion implantation, etc.). 
Accordingly, ROM 214 cannot generally be altered after fabrication. The purpose of such 
an implementation is to take advantage of the fast access times provided by masked 

1 0 ROMs. ROM 2 1 4 suitably comprises about 4K-20K bytes of memory, preferably at least 
16K bytes. In this regard, it will be appreciated that alternate memory devices may be 
used in place of ROM 214. Indeed, as semiconductor technology progresses, it may be 
advantageous to employ more compact fomtis of memory, for example, flash-EEPROMs. 
The SCOS controls infonnation flow to and from the card, and more particularly 

15 facilitates storage and retrieval of data stored within EEPROM 212. As with any 
operating system, the SCOS operates according to a well-defined command set. In this 
regard, a variety of kno>vn smart card operating systems are suitable for the purpose of 
this invention, for example, IBM's Multi-Function Card (MFC) Operating System 3.51 , 
the specification of which is hereby incorporated by reference. While the IBM MFC 

20 operating system employs the standard tree structure of files and directories substantially 
in accordance with 1S07816-4 (as detailed below), it will be appreciated by those skilled 
in the art that other operating system models would be equally suitable for 
implementation of the present invention. Moreover, it may be advantageous to allow 
certain aspects of operating system functionality to exist outside the card, i.e., in the form 

25 of blocks of executable code which can be downloaded and executed by the smartcard 
during a transaction (for example, Java applets. ActiveX objects, and the like). 

Given the general characteristics of smartcard 100 as outlined above, it will be 
apparent that a wide range of microcontrollers and contact-based smartcard products 
. known in the art may be used to implement various embodiments of the present 

30 invention. Suitable smartcards include, for example, the model ST16SF48 card, 
manufactured by SGS-Thomson Microelectronics, which incorporates a Motorola 6803 
microcontroller with I6K ROM. 8K EEPROM. and 384 bytes of RAM. It will be 



■ apprcciaied, however, ihai particular embodiments of the present invention might require 
more advanced microcontrollers with greater EEPROM capacity (i.e., in the range of 
about I2-16K). Such systems are well known in the art. 

Having thus described an exemplary- smancard 100 and IC 110. an overview ofa 
5 smartcard file structure in accordance with the present invemion will now be described. 
Referring now to Figure 4, file structure 400 is preferably used to store information 
related to card-holder preferences and various data useful for securing and paying for air 
travel, rental cars, hotel rescr\'ations and the like. More panicularly. file structure 400 
preferably comprises cardholder ID application 406, payment system application 408. 

10 airline application 410, hoicl system application 412, rental car application 414, and 
cardholder verification data 404. It will be appreciated by those skilled in the art that the 
term "application" in this context refers to self-contained regions ofdata all directed at 
a particular function (e.g., airline, hotel, etc.) rather than a block of executable software 
code, although the use of executable modules as part of any particular application falls 

1 5 within the scope of the present invention. 

Cardholder verification data 404 preferably houses data useful in verifying 
cardholder identity during a transaction. In a preferred embodiment, cardholder 
verification data 404 comprises two eight-byte cardholder verification numbers {i.e.. PIN 
numbers) referred to as CHVI and CHV2. 

20 Cardholder ID application 406 suitably comprises various files related to personal 

information of the cardholder (e.g., name, addresses, payment cards, driver's license, 
personal preferences and the like). Caixlholder ID application 406 is described in greater 
detail below in conjimction with Figure 5. 

Payment system application 408 suitably comprises information usefiil in effecting 

25 commercial transactions, e.g., account number and expiration date information 
traditionally stored on a magnetic-stripe credit card. Alternatively, Payment system 
application 408 comprises a ftill EMV-compliant application suitable for a wide range 
of financial transactions. Payment system application 408 is described further below in 
conjunction with Figure 6. 

30 Airiine application 410 suitably comprises data helpfiil in streamlining commercial 

airiine travel; for example, relevant personal preferences, electronic tickets, and frequent 



7 



flier informaiion. Airline application 410 is discussed in greater detail below in 
conjunction with Figure 7. 

Hotel application 412 suiiably comprises informaiion useful for securing and 
paying for hotel reservaiions, including an array of information and preferences 
5 associated with a list of preferred hotels as well space for electronic keys. Hotel 
application 412 is discussed in greater detail below in conjunction with Figure 9. 

Rental car application 414 suitably comprises data useful in expediting the process 
of car rental and return, including, for example, car preference and frequent rental 
information. Rental car application 4 1 4 is described in further detail below in conjunction 

10 with Figure 8. 

In each of the above mcnlioned applicaiions, sophisticated access and encryption 
schemes are preferably utilized in order lo allow multiple parlies to make use of certain 
file structures while preventing unauthorized enlo' into others. More specifically, 
partnering organizations {e.g., hotel chains, airlines, and rental car agencies) may create 

15 their own tailor-made file structures (i.e., "partner file structures'') within card 100. 
Details of the various security measures employed are described in further detail below 
in conjunction with Table 40. 

Referring now to Figure 10, smancard 100 is suitably used in the context of a 
distributed transaction system. Briefly, cardholder's may employ smartcard 100 at 

20 various access points 1 5 which are connected via network 1 9 to an issuer 1 0 and at least 
one partnering organization 12. Issuer 10 suitably comprises various hardware and 
software components suitable for client host communications as well as a database 
system 1.1 . In this context, the leim 'issuer' refers to the organization that actually issues 
the smartcard and retains some high-level access to certain areas of file structure 400 

25 (detailed below). 

Partnering organizations 12(a), 12(b), and so on, comprise the various hotel chains, 
rental-car agencies, airiines, and the like, who have access to appropriate data regions 
within smartcard 1 00. Each partnering organization 1 2 suitably comprises a database 1 3 
and appropriate hardware and software components necessary for completing a 

30 transaction over network 19. Network 19 may comprise one or more comniunication 
modes, e.g., the public switched telephone network (PSTN), the internet, digital and 
analog v^'reless networks, and the like. 



Each access point 1 5 suhably comprises an appropriate card reader for interfacing 
with smartcard 100 as well as hardware and software suitable for interfacing with a 
cardholder and performing a transaction over ncnvoric 1 9. Access points 1 5 are preferably 
located in areas providing convenient access for traveling cardholder's or cardholder's 
5 preparing travel arrangements. Such access points 15 may be located, for example, in 
airline ticketing and gate areas, rental car facilities, hotel lobbies, travel agencies, and 
stand-alone kiosks in malls. In addition, businesses might see fit to host an access point 
15 to streamline their employees' business travel. Furthermore, an individual cardholder 
might configure his or her personal computer to act as an access point using appropriate 

10 software and peripheral hardware. 

In a preferred embodiment of the present invention, data files and directories are 
stored in a "ircc" .stnicturcas illustrated in Figure 3. Thai is. ihc smartcard file structure 
resembles the well known MS-DOS (Microsoft Disk Operating System) file structure 
wherein files are logically organized vwthin a hierarchy of directories. Specifically, three 

1 5 types of flics are defined in ISO 7816-4: dedicated files (DF), elementary files (EF), and 
a master file (MF). The master file is analogous to the MS-DOS "root" directory, and 
contains all other files and directories. Dedicated files are actually directories or "folders" 
for holding other DFs or EFs. Thus, MF 302 may contain an arbitrary number of DFs 
306, and these DFs (e.g., DF 306(a)) may or may not contain other DFs (e.g., DF 308). 

20 Elementary files are used to store user data, and may exist within a dedicated file (e.g., 
EF 3 1 0 within DF 306(a)), or within the master file (e.g., EF 304 within MF 302). Higher 
level DFs (i.e., DFs which house particular applications) are often referred to as 
application dedicated files (ADFs). 

The MF and each of the DFs and EFs are assigned a unique two-byte file identifier 

25 (FID). By convention, the MF is traditionally assigned an FID of jFOO' hex. Selection 
of an EF or DF by the operating system may then be perfonmed by tracing its entire path 
starting at the MF. Thus, if the MF contains a DF wath a FID 'AlOO', and this DF in turn 
contains an EF with a FID 'A 101', then this EF could be referenced absolutely by 
successive selection of FIDs 3F00, A 1 00, and A 1 01 . It will be appreciated that the FID 

30 is essentially a file name used by the operating system to select directories aiid files; il 
is not intended to indicate a physical address within EEPROM 212. As will be 
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appreciated by those skilled in the an. low-levcl EEPROM addressing is preferably 
handled by the SCOS in conjunction with CPU 202. 

Each file preferably has an a.ssociaied file header containing various indicia of the 
particular EF, DF, or MF. More particularly, the file header associated with a particular 
file preferably includes ilie file identifier (FID), file size, access conditions, and file 
structure. In this regard, smartcard 100 suitably employs one of four file structures: 
transparent, linear fixed, linear variable, or cyclic. For the sake completeness, the nature 
of these file structures will be briefly reviewed. 

A transparent file structure consists of a string of bytes accessed by specifying an 
offset and byte count. For cxnmple. with reference to Tsibic I below, given a n-byte 
string of data, bytes 7 through 1 0 would be accessed using an offset of six and a length 
of four. 



byteff 




•offsei > < length 



Table 1 : Transparent file structure 

A linear fixed file structure comprises a plurality of records of equal length (e.g., 
a list of phone numbers), wherein access to an individual record is achieved through 
reference to a record number. In addition, it is possible to refer to the 'next' or "previous' 
record relative to the 'current* record (i.e., the most recently accessed record). In contrast, 
a linear variable file structure comprises records of arbitrary but known length, and is 
therefore typically more compact than linear fixed data structures. 

A cyclic file structure is a type of linear fixed file wherein a pointer is used to point 
to the last data set written to. After the last data record is written to, the pointer returns 
to the first record. That is, a cyclic file comprises a series of records arranged in a "ring*. 

A data structure particularly important with regard to storing records as well as 
secure messaging in smartcard applications is the BER tag-length-value or "TLV 
structure in accordance with ISO/IEC 8825. hereby incoiporated by reference. In a TLV 
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object, information regarding the type and length of the information is included along 
with the actual data. Thus, a TLV object comprises a tag which identifies tlie type of data 
(as colled oui by the appropriate specification), a length field which indicates the length 
in bytes of the data to follow, and a value field, which comprises the primary data. For 
example, the TLV object illustrated in Tabic 2 below encodes the text "phoenix", which 
has a length of 7 bytes, and corresponds to a the "city" tag of 'SC hex (a hypothetical tag 
designation). 





Tag 


Length 


Value 




10 




'07 






o 1 . 1 






X 



TABLE 2: E-xemplary primitive TLV object 



It will be appreciated that the meaning of the various tag values must be known to 
the system a priori. That is, in order for the tag field to be useful, the smancard and any 
external systems communicating with the smancard must conform to the same tag 

1 5 specification. In this regard, ISO/lEC 781 6-6 defines a series of lags useftil in the context 
of the present invemion. as does the IBM MFC 3.2 specification. ISO/lEC 8825 sets 
forth the basic encoding rules for a TLV system and defines a "template" data object 
which can be used as a container for multiple TLV objects. That is, it is often 
advantageous to encapsulate primitive TLV objects within a larger template which is 

20 itselfa TLV object. 

Referring now to Figure 4. a preferred smancard data structure in accordance with 
the present invention will now be described in detail. Data structure 400 preferably 
comprises a MP 402 and five DFs: Cardholder ID application 406. Payment system 
application 408, Airiine application 410, Hotel application 412, and Rental car 

25 application 414. 

In the detailed description to follow, various acronyms and abbreviations will be 
used to refer to particular data types, formats, and the like. A key to these acronyms and 
abbreviations is presented in Table 3 below. 

AN Alphanumeric 
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N Numeric 

B Boolean 

C Convention 

M Matrix 

D Data 

AR Bits array 

BIN Binary 

RJ Right-justified 

U Left-justified 

BCD Binary coded decimal 

TABLE 3: Key to acronyms 
In the discussion that follows, the various features of a preferred data structure 
are in some cases described using particular file structure types (i.e., transparent, 
fixed, etc.). Those skilled in the an will realize, however, that any of the common 
smaricard file structure types are typically suitable for implementing any particular 
data structure. For example, when a file structure is described as including "a plurality 
of records," it will be understood that such a structure may be designed, for example, 
using a list of records assembled in a linear fixed file wherein each record is itself a 
transparent file (and offset values correspond to the various fields). Alternatively, 
such a structure may be designed using TLV strings assembled in a linear fixed file or 
within a larger template TLV. Tliis is the case notwithstanding the fact that particular 
tag values - which are for the most part arbitrary - arc not explicitly listed in the 
tables that follow. 



Cardholder ID Application 

RefeiTing now to Figure 5, Cardholder ID application 406 is used to store various 
information related to the cardholder. Portions of this information are freely available to 
the partnering organizations, thereby preventing the storage of redundant information. 

More particulariy, cardholder ID application 406 preferably comprises dircctoiy 
EF 532. holderJD DF 502 and miscellaneous DF 530. HolderJD DF 502 preferably 
comprises ID EF 504. home EF 506. business EF 508. preferences EF 514, passport EF 
516, authentication EF 520, biometric EF 522, and driver EF 518. Miscellaneous EF 530 
preferably comprises payment card EF 510. sequence EF 512, issuance EF 51 1, preferred 
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programs EF 528, and card number EF 526. Thtsc files and iheir respective functions arc 
discussed in detail below. 

Direciory EF 532 provides a list of application identifiers and labels for the various 
hisih-level DF's existing under cardholder ID application 406. Tliat is, this file serves the 
function of a high-level direcior>' lisiing which specifics ihe location (i.e., FID) and 
application label for each DF - in this case. holder^lD DF 502 and miscellaneous DF 
530. In a particularly preferred embodiment, directory EF 532 is structured in accordance 
with EMV 3-0 as shown in Tabic 4 below. Preferably, each major application (e.g., hotel, 
airline, etc.) has an associated directory file with a substantially same file structure. 



Record Rescript ion 


Mxicriinl rornini 


tnicriKil for 111 at (by ICS) 




Size 


Type 


Size 


Type 


Application ID for ho]der_ID DF 


16 


AN 


16 


ASCII 


Application label 


16 


AN 


16 


ASCII 


Application ID for miscellaneous DF 


16 


AN 


16 


ASCII 


Application label 


16 


AN 


16 


ASCII 



Tabic 4: Exemplar)' cardholder ID directory EF 



ID EF 504 preferably includes personal infonnalion related to the cardholder, e.g., 
name, dale of birth, emergency contact, general preferences, and the like. In a particularly 
preferred embodiment, member EF 504 comprises the fields set forth in Table 5 below. 
Italicized field names indicate a subcategory within a particular field. 



Record description 


External format 


Infernal rormat(bytes) 




Size 


Type 


Size 


Type 


Last Name 


30 


AN 


30 


ASCII 


First Name 


20 


AN 


20 


ASCII 


Middle Name 


S 


AN 


S 


ASCII 


Honorary Title 


S 


AN 


8 


ASCII- 


Name Suffix 


A 


AN 


A 


ASCII 


Date of Birth 


S 


D 


4 


BCD 
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Social SeciiriiY Number 


10 


AN 


10 


ASCII 


Emergency Conuci 










Lasf Name 


20 


AN 


20 


ASC/I 


rirsi Nome 


10 


AN 


10 


ASCIJ 


Relotion 




/' 


1 


BIN 


Phone 


20 


N 


10 


BCD 


Gender 


I 


AN 


J 


ASCII 


Special Personal Rcquircmenis 


12 


AN 


12 


M 


Lansunge Preference (ISO 639) 


2 


C 


2 


ASCII 



10 



Table 5: Excmplnry ID EF data slruclurc 



In the above table, and ilic tables to follow, both internal and external data 
formats are listed. As the conservation of EEPROM space is of paramount 
importance, the "internal" fomiat of data (i.e.. within EEPROM 212) may be 
different from the "external" format of the data (i.e., as read by the card reader at 
1 5 an access point 1 5). Thus, for example, a date field might consist of a four-byte 
BCD record within the card, but upon reading and processing by the terminal, this 
data might be converted to an eight-byte decimal value for more convenient 
processing. 

Home EF 506 preferably includes data related to one or more of the 
20 cardholder's home addresses. In a particularly preferred embodiment, home EF 506 
comprising the fields set forth in Tabic 6 below. The personal travel charge account 
pointer is preferably used to designate a preferred payment card, and consists of a 
number corresponding to one of the paymem card records within payment card EF 
510 (detailed below). 



Record description 


External format 


Internal for 


Tnat(bytes) 




.Size 


Type 


Size 


Type 


Home Address I 


40 


AN 


40 


ASCII 


Home Address 2 


40 


AN 


40 


ASCII 


Home Address Ciiy 


25 


AN 


25 


ASCII 



25 
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Home Address Smic 


> 


AN 


< 


ASCI) 


Home Coumry(!S0 3I66) 


-J 


ak 

i\v* 




ASCI] 


Home Address Zip Code 


10 


AN 


10 


ASCII 


Home Address Telephone 


20 


r* 


in 


BCD 


Home Address FAX 


20 


N 


to 


BCD 


Home E-mail address 


40 


AN 


40 


ASCII 


Personal travel charge accouni number 
poimer 


2 


N 


I 


BCD 



T:iblc 6: Exemplary home EF file structure 



1 0 Business EF 508 preferably includes various data related to the cardholder's 

business (i.e., addresses, phone numbers, and the like). In a particularly preferred 
embodiment, business EF 508 comprising the fields set forth in Table 7 below. In 
this regard, the credit card poimer field is preferably used to point to a payment card 
record within payment card EF 510 (detailed below). The cost center, dept., 

1 5 division, and employee ID fields are employer-specific, and may or may not apply 
in a given case. 



Record dcscripiion 


External ronnaf 


Internal for 


maf(bylc$) 




Size 


Type 


Size 


Type 


Business Address 1 


40 


AN 


40 


ACSII 


Business Address 2 


40 


AN 


40 


ASCII 


Business Address Ciiy 


25 


AN 


25 


ASCII 


Business Address Siaie 


5 


AN 


5 


ASCII 


Business Countiy (ISO 3 1 66] 


2 


AN 


2 


ASCII 


Business Address Zip Code 


10 


AN 


10 


ASCII 


Business Telephone No. 


20 


N 


10 


BCD 


Business Address Fax 


20 


N 


10 


BCD 


Business E-mail Address 


40 


AN 


40 


ASCII 


Professional TiUe 


10 


AN 


10 


ASCII 


Employee ID 


10 


AN 


10 


ASCII 
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Division 


20 


AN 


20 


ASCII 


Ocpi 


20 


AN 


20 


aC^II 

AoCli 


Cost Center 


12 


AN 


12 




I^ofcssional travel accouni number 

poinicr 


A. 




2 


BCD 


Professional license data 


20 


AN 


20 


ASCII 


Credit Card pointer 


2 


N 


1 


BCD 


Company Name 


20 


AN 


20 


ASCII 



Tabic 7: Excmplarj' business EF file structure 



10 Preferences EF 514 preferably comprises data related to ihc cardholder's 

default personal preferences. In a particularly preferred embodiment, preferences 
EF 514 includes a field comprising an array of preferences as set forth in Tabic 8 
below. Preference values arc preferably chosen from a list of preference tags as set 
forth in Tabic 39. 
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Record description 


External formal 


Internal for 


'niaf(bytcs) 




Size 


Type 


Size 


Type 


Preferences Array 


20 


C 


20 


C 



Tnbic 8: Examplar)' preferences EF file structure 



Passport EF 516 is preferably used to store cardholder passport information. 
20 In a particularly preferred embodiment, passport EF 516 comprises the fields set 
forth in Tabic 9 below. 



Record description 


External format 


Internal for 


fnat(byies) 




Size 


Type 


Size 


Type 


Passport Number 


20 


AN 


20 


ASCII 


Passport Country — ISO 3 1 66 


2 


AN 


2 


ASCII 


Issuance Date 


8 


D 


4 


BCD 
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City of Issuance 


20 


AN 


20 


AN 


Expiration Date 


8 


D 


4 


BCD 



Tabic 9: Examplary passpori EF file siruciure 



Driver EF 516 preferably comprises cardholder driver license daia. In a 
particularly preferred embodiment driver EF 518 comprising the fields sci fonh in 
Tabic 10 below. 



Record description 


External format 


Internal foi 


'in3t(bytcs) 




Size 


Type 


Size 


Type 


Driver's License No. 


20 


a 


20 


ASCII 


Driver's License Issuing Staie/Counirj' 


2 


a 


2 


BCD 


License Expiration Dale 


S 


D 


4 


ASCII 


License Type 


2 


C 


4 


BCD 



Tabic 10: Exemplary driver EF file siruciure 



Biomeiric EF 522 is used lo store biomeiric data (preferably encoded) such 
as fingerprint data, rclina scan data, or any oiher sufTicicnily unique indicia ihe 
cardholder's physical or behavioral characteristics. In a particularly preferred 
embodimeni. biomeiric EF 522 comprises a single data siring as set forth in 
Tabic Jl below. 



Record description 


External format 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Biometrics template 


too 


AN 


100 


BIN 



Tabic 11: Exemplar)' biomeiric EF file siruciure 



Authentication EF 520 preferably comprises informaiion for sialic 
auihenlicalion of ihe cardholder ID 406 applicaiion. This data is unique for each 
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card, and is sufTicicntly complex such that counterfeit values cannot feasibly be 
create<J. This prevents creation of "new" counterfeit cards (i.e., cards with new 
authentication data), but does not prevent creation of multiple copies of the 
current card. 

In 0 particularly preferred embodiment, authentication EF 520 includes 
public key certificate fields as shown in Tabic 12 below, wherein the external 
format is identical to the internal format. Preferably, the issuer RSA key is 640 
bits long, and the CA key is 768 bits long. 



10 



Record dcscripiion 


Internal for 


mat(bytes) 




Size 


Type 


Signed Sialic Applicaiion Data 


SO 


B 


Sialic Daia Auihcniicaiion Tag Lisi 


16 


B 


Issuer Public Key Ccnificaic 


96 


B 


Issuer Public Key Exponent 


I 


B 


Issuer Public Key Remainder 


20 


B 



15 



Table 12: Exemplary authentication EF 
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Turning now to files under miscellaneous DF 530, preferred programs EF 
528 preferably comprises data related to the cardholder's preferences as to airline 
companies, hotels, and rental car agencies. Specifically, this EF, in a particularly 
preferred embodiment, comprises a plurality of records (e.g., three) indicating 
prefeiTCd companies for each type of travel partner as shovw in Table 13. The 
actual data values conform to an arbitrary convention; that is, each airline, hotel, 
and rental car agency is assigned an arbitrary three-byte code. 
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Record description 


Exicrnal formal 


Internal for 


mat(bytes) 




Size 


Type 


Size 


Type 


Preferred Airlines 


9(3x3) 


C 


9 


C 


Preferred Hotels 


9 


C 


9 


C 


Prcfcacd Rental Cars 


9 


c 


9 


C 
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Tabic 13: Exemplar)' programs EF 



Payment card EF 5 1 0 is preferably used to caialog information related to the 
cardholder's various payment cards, i.e., debit cards, charge cards, and the like. In 
a particularly preferred embodimeni. payment card EF comprises card numbers and 
expiration dates for two cards as shown in Table 14. The "ISO" and "non-ISO" 
designations refer to 1SO-7SI3, which specifies a particular payment card number 
formal. Thus, in a preferred embodiment, either an ISO or non-ISO card number 
scheme may be used. Moreover, it will be appreciated that this data set is sufficient 
only for "card not present" transactions, for example, transactions taking place 
remotely where only ihc card number and expiration date arc required to effect a 
transaction. Data stored within payment system application 408 (described below) 
must be used to effect a "card present" transaction. 



Record description 


External formal 


Internal format(bytcs) 




Size 


Type 


Size 


Type 


First Paymcnl Card # (ISO) 


19 


N 


10 


BCD 


Firsi Paymcnl Card Expiraiion Date 


S 


D 


4 


BCD 


Second Payment Card # (non-ISO) 


20 


AN 


20 


ASCII 


Second Payment Card Expiration Date 


S 


D 


4 


BCD 



Table 14: Exemplary payment card EF file structure 



Sequence EF 512 preferably includes information used to provide 
synchronization of the host and smancard databases. In a particularly preferred 
embodiment, sequence EF 512 comprises a plurality of records comprising the field 
set forth in Tabic 15 below. This number is analogous to a "version" number for 
the data stored in the application. 



Record description 


External format 


internal forma ((bytes) 




Size 


Type 


Size 


Type 



19 



Sequence Number 


16 


AN 




ASCII 



Tabic 15: Exemplar)' sequence EF file structure 



Card number EF 526 is used lo record a unique number identifying the 
smartcard, and may also be used for key derivation (as described in further detail 
5 below). Preferably, card number EF 526 comprises a eight-byte string as set 
forth in Tabic 16 below. 



Record description 


External format 


Internal for 


'mat(bylcs) 




Size 


Type 


Size 


Type 


Card Number 


S 


HEX 


S 


HEX 



Tabic 16: Exemplary card number EF 



1 0 Issuance EF 5 11 is used lo record various details related to the manner in 

which the application (i.e., cardholder ID DF 406) was created. This file includes 
information related to the identity of the organization ihat created the 
application, as well as information related to the application itself. In a 
particularly preferred embodiment, issuance EF 51 1 comprises fields as set forth 

15 in Tabic 17 below. 



Field 


Exicrnal Tormal 


Internal fc 


»rnial (bytes) 




Size 


Type 


Size 


Type 


Country Authority 




1503166 


2 




Issuer Authority 


10 


RJD • ISO 
7816-5 


5 


HEX 


Application version 


5 


XX.YY 


2 


BCD 


Application expiration date 


S 


YYYYMM 
DD 


A 


BCD 


Application effective date 


8 


YYYYMM 

DD 


4 


BCD 
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Personalizer Code 


1 


AN 


1 


ASCII 


Personalization Locaiion 


1 


AN 


I 


ASCII 



Tabic 1 7: Exemplary issuance EF file structure . , 
The personalizer code field shown in Tabic 17 refers lo the organization 
thai actually "personalizes" the file. Thai is, before a smartcard may be issued to 
the cardholder, the database structure must be created within EEPROM 212 
(Figure 2), and the initial data values (i.e., default preferences, cardholder name, 
pin numbers, etc.) must be placed in the appropriate fields within the various 
EFs. It will be appreciated that, given the nature of the present invention, the 
smartcard "issuer" and "personalizer" for any given application may not be the 
same. Therefore, it is advantageous to record various details of the 
personalization process within smartcard 100 itself Similar issuance file 
structures may be provided for the other major applications. 

Payment System Apph'cation 

Referring now to Figure 6, payment system application 408 preferably 
comprises a directoiy EF 610, issuer DF 602, and a number of optional DFs 603(a)- 
(n) for use by partnering financial organizations. 

Directory EF 610 preferably includes a list of application identifiers and 
labels as described above in the context of cardholder ID application 406. 

Issuer DF 602 comprises payl DF 604, which includes data that would 
traditionally be stored within tracks on a magnetic stripe card (i.e., debit cards, 
charge cards, and the like). In a preferred exemplary embodiment, payl DF 604 
comprises a plurality of records having commonly known magnetic-stripe fields as 
specified in Table 18 below. 



Record description 


External format 


internal Tor 


mat(bytcs) 




Size 


Type 


Size 


Type 


Format Code (Track 1 ) 


1 


AN 


1 


ASCII 



21 



PAN (Track 2) 


15 


N 


8 


BCDF 

padding 


Expiraiion date ( Track 1 or 2 ) 


A 


YYMM 


2 


BCD 


Effective dale { Track 1 or 2 ) 


4 


YYMM 


2 


BCD 


Discretionary data ( Track 1 or 2 ) 


5 


N 


3 


BCDF 

right 

pndding 


Name ( Track 1 ) 


26 


AN 


26 


ASCII. U 

blank 

padding 



T;iblc 18: Exemplar}' Payl EF file structure 



Airline Application 

Referring now to Figure 7, airline application 410 preferably comprises 
directory EF 730, common DF 702, and issuer DF 704, and additional airline 
applications 703(a), 703(b), and so on. 

Directory EF 730 preferably includes a list of application identifiers and 
labels as described above in the context of cardholder ID application 406. 

Common DF 702 generally includes data accessible to all participating 
airlines, while issuer DF 704 generally includes data which can only be read or 
written to by the smartcard issuer. Airline application 410 preferably further 
comprises at least one (preferably three) additional DF 703 for use by airline 
partnering organizations. That is, one airline partner may have access lo and specify 
the structure of data stored within DF 703(a) (as well as common EF 702), while 
another airline might have similar access to DF 703(b). These partner DFs 
preferably conform to the relevant portions of the lATA specification. 

Common DF 702 suitably comprises common daU which would be of use to 
any of the various partnering airlines, i.e., passenger EF 706, frequent flier EF 708, 
JET EF 710, boarding EF 712, and biomelric EF 714. 
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Issuer DF 704, in conirasu comprises information readable by all, but 
updaiable only by the card issuer, i.e., preferences EF 716, PIN EF 718. and 
issuance EF 720. 

Referring now to information stored within common EF 702, passenger EF 
706 preferably comprises various records related to the passenger as specified in 
Tabic 19 below. 



Record description 


External rormal 


Internal for 


mat (bytes) 




Size 


Type 


Size 


Type 












Passenger Name 


49 


AN 


49 


ASCII 


Gender 


1 


A 


1 


BIN 


Language Preference 


2 


AN 


2 


ASCII 


Unique ID 


24 


AN 


24 


ASCII 


Airline ID (3 letters code ) 


3 


AN 


J 


ASCII 


Type code ( 2 letters ) 


2 


AN 


2 


ASCII 


Unique JD 


19 


AN 


19 


ASCII 


Application version 


2 


N 


2 


BIN 



Tabic )9: Exemplary passenger EF file structure 



In a particularly prcfenred embodiment, frequent flyer EF 708 comprises a 
plurality of frequent flier numbers (e.g., ten numbers) having the structure specified 
in Table 20 below. 



Record description 


External formal 


Internal for 


mat (bytes) 




Size 


Type 


Size 


Type 


Airline Customer ID 


22 


AN 


22 


ASCII 



Tabic 20: Exemplary frequent flyer EF file structure 



23 



IE*r EF 710 prefcnibly comprises a plurality ofelecironic ticket records as set 
forth in Tabic 21 below. The rbmiai of these electronic tickets preferably conforms 
to the lATA standard. 



Description of ilic records 


External forninf 


Internal form»l (bytes) 




Size 


Type 


Size 


Type 


lET 1 


M 


AN 


14 


BIN 


IET2 


14 


AN 


14 


BIN 


IET3 


)4 


AN 


14 


BIN 


IET4 


M 


AN 


14 


BIN 


IET5 


U 


AN 


14 


BIN 



T;ible 21 : Exemplary lET file structure 



In a particularly preferred embodiment, boarding EF 712 comprises boarding 
data to be used during check in as specified in Table 22. The format of this data 
preferably conforms to the 1 ATA specification. 



Record description 


External formal 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Boarding daia 


40 


AN 


40 


ASCII 



Tabic 22: Exemplary boarding EF file structure 



Biometric EF 7H is suitably used to store biometric data associated with the 
cardholder, e.g., retina scan data, fingerprint data, or any other sufficiently unique 
indicia of the cardholder's physical or behavioral characteristics. In a particularly 
preferred embodiment, biometric EF 714 comprises data as specified in Table 23 
below. 



Record description 


External formal 


Internal format (bytes) 




Size 




Size 


Type 



24 



Oiomeirics dam 


100 


AN 


ICQ 


BIN 



Table 23: Exemplary biometric EF file structure 



Issuance EF 720 is suitably used to hold daia related to the issuance of the 
various applicaiions. In a particularly preferred embodimenl, issuance EF 720 
comprises a data siruciure as specified in Tabic 24 below. 



Field 


Exicrnsil format 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Couniry Auilinriiy ( 2 Iciicrs ) 




IS03166 


2 




Issuer Authority 


10 


RID -ISO 
7816-5 


5 


HEX 


Applicaf ton version 


5 


XX.YY 


2 


BCD 


Application expiration date 


8 


YYYYMM 
DD 


4 


BCD 


Application effective date 


8 


YYYYMM 
DD 


A 


BCD 


Personalizer Code 


1 


AN 


1 


ASCII 


Personalization Location (custom code) 


1 


AN 


I 


ASCII 



Tabic 24: Exemplary issuance EF file structure 



PIN EF 718 is suitably used lo store PIN values corresponding lo each of the 
participating airline partners. In a particularly preferred embodiment, PIN EF 71 8 
comprises a plurality of records having the structure specified in Tabic 25 below, 
wherein each record is related to the corresponding entry in frequent flyer EF 708 
(i.e., record one in EF 718 corresponds to record one in EF 708, and so on.) 



Record description 


External format 


Internal formal (bytes) 




Size 


Type 


Size 


Type 


PIN 


8 


AN 


8 


BIN 


Expiration date 


8 


D 


4 


BCD 
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Tabic 25: Exemplary PIN EF file structure 



Preferences EF 716. in a particularly preferred embodiment, comprises a 
preferences array as shown in Tabic 26 below. TTie preference values stored in this 
flic correspond to those discussed below in conjunction with Tabic 38. 



Record description 


ExicrnnI format 


Internal for 


mat (byCcs) 




Size 


Type 


Size 


Type 


Preferences Array 


8 


C 


8 


BIN 



Tabic 26: Exemplary preferences EF 716 file structure 



10 



15 



20 



Rental Car Application 

Referring now to Figure 8, rental car application 414 preferably comprises 
common DF 802, directory EF 820, and one or more rental_car DFs 803 (i.e.. 
803(a), 803(b). and so on) corresponding to individual rental car agencies. 

Common DF comprises preferences EF 805, which is described in detail 
below. Rcntal_car DFs 803 each comprise a rental_car_id EF 807, reservation EF 

809, and expenses EF 81 1 . 

Directory EF 820 includes a list of application identifiers and labels for the 
various DFs under rental_car application 414. The structure of this EF preferably 
conforms to that described above in the context of cardholder JD application 406. 

In a particulariy preferred cmbodimeni, preferences EF 805 comprises a set 
of preferences arrays file structure as shown in Table 27 below. A preferred list of 
preference codes for use in each of these arrays is described below in conjunction 
with Table 38. 



25 



Record description 


External format 


Internal for 


mat( bylcs) 


Preferences Array (Default) 


8 


C 


8 


BIN 


Preferences Array (No. 2) 


8 


C 


8 


BIN 


Preferences Array (No. 3) 


8 


c 


8 


BIN 


Preferred limousine company 


12 


AN 


12 


ASCII 



Table 27: 
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Renial_car id S07 is used to store frequent rental information, upgrade 
information, insurance infonnation. and the like. In a particularly preferred 
embodiment, rentaLcarjd 807 comprises a file structure as shown in Tabic 28 
below. 



Record description 


External format 


Infernal fornial( byies) 


Frequent Rental 10^ 


22 


A 


22 


ASCI! 


Company name 


3 


A 


i 


ASCII 


Uniqve Customer JD 


19 


A 


19 


ASCII 


CDP (Contract Disc. Program) 


10 


A 


10 


ASCII 


Accumulated points 


S 


N 


3 


BIN 


Renial features 




AR 


2 


BIN 


Cor Type Upgrade 




B 


/ 6/7 


B 


Week-end/Vacaiion Special 




B 


/ bit 


B 


Guaranteed Late Reservation 




B 


} bit 


B 


Insurance 




Array 


7 


BIN 


Loss Damage Waiver (LOW) 




B 


1 bit 


B 


Persona/ Automobile insurance 




B 


/ bit 


B 


Personal Effects Coverage 




B 


/ hii 


B 


Personal Insurance 




B 


I b it 


B 


Corporate Insurance 




B 


/ h it 


B 



Table 28: Exemplary renial^carjd EF 



Reservation EF 809 is used to store confirmation numbers corresponding to 
one or more rental car reservations. In a particularly preferred embodimcnl, 
reservation EF 809 comprises a plurality of records (e.g., two) haviiig a file 
25 structure as shown in Table 29 below. 



Record descriplion 


Exfernal format 


Internal rormat( bytes) 


Rental Car Company 


3 


A 


3 


ASCII 
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Locniion 


5 


A 


3 


Acr*i 1 


Date 


S 


D 


4 




Time 


A 


T 


2 




Reservalion Number 




A 


15 


ASCII 


Fligln Number 


5 


M 


5 


BIN 


Airlines 


S 


^A' 


J 


AScn(RJ) 


Flight numb(fr 


4 


N 


2 


BCD 


Preferred profile 


1 


C 




ASCII 



Tabic T)\ Exemplary reservation EF 



1 0 Expenses EF 8 1 1 is used lo record expenses incurred by the cardholder during 

car rental (e.g., the total rental charge). In a particularly preferred embodiment, 
expenses EF S 1 1 comprises a plurality of records (e.g., five) having a file structure 
as shown in Table 30 below. 



Record description 


External format 


Internal formatC bytes) 


Type of expense 


1 


C 


I 


ASCII 


Date 


S 


D 


4 


BCD . 


Location code 


3 


AN 


3 


ASCII 


Amount 


7 


N 


3 


BIN 



Tnbic 30: Exemplary expenses EF 

20 

Hotel Application 

Referring now to Figu re 9, hotel system application 4 1 2 preferably comprises 
directory EF 920, common DF 914, one or more hotel chain DFs 902, and one or 
more property DFs 903. 
25 Common DF 914 comprises reservation EF 918, expenses EF 916, key-of- 

ihe-room EF 910, and preferences EF 912. 



28 



Hotel chain EFs 902(a), 902(b), and so on, comprise preferences EF 904 and 
stayer JD EF 906 associated with individual hotel chains. In contrast, property EFs 
903(a), 903(b). and so on. comprise a similar file structure associated with 
individual hotel properties (i.e., independent of whether the particular hotel is a 
5 member of a nationwide chain). 

In a pariiculariy preferred embodiment, reservation EF 918 comprises a 
plurality of records having the structure sliown in Tabic 31 below. In general, this 
EF is used to store confirmation numbers transmitted to smaricard 100 when the 
cardholder makes a reservation at a given hotel (designated in the property code 
10 field). The date field stores tlie date on which the confirmation number was 
dispensed. 



Record dcscripCion 


External formal 


Internal for 


nial(byics) 




Size 


Type 


Size 


Type 


Property Code 


3 


AN 


3 


ASCII 


Date 


S 


D 


4 


BCD 


Confiniiaiion Number 


15 


AN 


15 


ASCII 



Tabic 31 : Exemplary reservation EF 



Preferences EF 912 preferably comprises three sets of array preferences. The 
particular codes used in these arrays are discussed below in conjunction with Table 
38. 



20 



Record description 


External formal 


Internal for 


mat(bytes) 




Size 


Type 


Size 


Type 


Preferences Array (default) 


S 


c 


8 


BIN 


Preferences Array (number 2) 


8 


c 


8 


BIN 


Preferences Array (number 3) 


S 


c 


8 


BIN 



Table 32: Exemplary preferences EF 
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Expenses EF 916 preferably comprises a list of recem hotel expenses, for 
example, room costs, dinner expenses, and the like. In a particularly preferred 
embodiment, expenses EF 916 comprises a plurality of records (for example, 
fifteen) arranged in a cyclic file structure and comprising the fields shown in Table 
33 below. Thus, the cardholder is able to examine and print a list of recently 
incurred expenses by type (a code fixed by convention), date, amount, and property 
code. 



Record description 


External format 


Internal for 


fnat(bytes) 




Size 


Type 


Size 


Type 


Type 


1 


C 


1 


ASCII 


Date 


S 


D 


A 


BCD 


Propcny Code 


3 


AN 


3 


ASCII 


Amouni 


7 


N 


3 


BIN 



Tabic 33: Exemplary expenses EF 



Key-of-the-room EF 91 0 preferably comprises electronic key values thai can 
be used in conjunction with card readers to provide access to particular hotel rooms. 
In a particularly preferred embodiment, key-of-the-room EF 910 comprises a 
plurality of alphanumeric key values as shown in Tabic 34 below. 



Record description 


External format 


Internal format(bytcs) 




Size 


Type 


Size 


Type 


Key value 


40 


AN 


40 


BIN 



Tabic 34: Exemplary key-of-lhe-room EF 



Slayer ID EF 906 preferably comprises frequent stayer data for a particular 
hotel chain. In a particularly preferred embodiment. Slayer ID EF 906 comprises 
frequent stayer information as shown in Table 35 below. 
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Record description 


External format 


Internal 
formsit{by 


Its) 








Size 


type 


Frequent stayer number 


19 


AN 


IV 




Frequent Stayer Level Code 


1 


AN 


1 


ASCII 


Frequent Suyer Level Expiration Date 


6 


YYYYMM 


3 


BCD 


CD? 


10 


AN 


10 


ASCII 


Event Counter 


3 


N 


1 


BIN 


Hotel Frequent Stayer PIN 


8 


AN 


8 


BIN 



Tabic 35: Exemplary stayer ID EF 



Preferences EF 904 preferably comprises three sets of array preferences as 
shown in Tabic 36. The particular codes used in these arrays are discussed below 
in conjunction with Tabic 38. 



Record description 


External format 


Internal for 


mat(bytc5) 




Size 


Type 


Size 


Type 


Preferences Array (default) 


8 


C 


8 


BIN 


Preferences Array (number 2) 


8 


C 


8 


BIN 


Preferences Array (number 3) 


S 


c 


8 


BIN 



Tabic 36: Exemplary preferences EF 



Property DFs 903(a), 903(b), etc., arc used in cases where the partnering hotel • 
is not part of a major chain, or when the hotel chooses to employ its own data set 
independent of its affiliation. In one embodiment, these property DFs arc identical 
20 in structure to hotel chain DFs 902, except that much of the frequent stayer ID 
information is removed. More specifically, a typical property DF 903 comprises a 
preferences EF 938 identical to preferences 904 described above, along with a 
stayer ID EF 934 which includes only the CDP, event counter, and hotel frequent 
stayer PIN fields described in conjunction with Table 33 above. Alternatively, a 
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particular hotel chain or property mighi choose lo implement a 
structure than that described above. 



Preference Codes 

AS meniioned brielly above, a prefeired cmbodimcni is configured such (hat 
preferences arc located in several files distributed throughout smartcard 100; i.e.. 
in preferences EF 514, airline preferences EF 716, hotel preferences EF 912 and 
904, and car preferences EF 810. This allows apparently conflicting preferences to 
co«^ist vsrithin the carf depending on context. For example, it is possible to opt for 
non-smoking in the cardholder ID application while choosing the smoking option 
within the hotel application. In ihc ca.sc of conflict, preferences are read from the 
top level to the bottom level, and each level supersedes the previous one. 

An exemplary set of codification rules arc set forth in Table 37 below: 

0-49 General purpose (Cardholder ID 406) 

50-99 Hotel application 412 

100-149 Rental car application 414 

1 50- 1 99 Airline application 4 1 0 

200-255 Other 

Tabic 37: Exemplary Preferences Code Ranges 

More specifically, in a prefeired excmplao- embodiment, preference flags are 
coded as set forth in Table 38 below. 



Preference 


Code (decimal) 


GENERAL PURPOSE 




Smoking 


00 


Non-smoking 


01 


Home as preferred address 


02 


Work as preferred address 


03 


Handicapped 


04 



32 



15 



Home zs preferred e-mnil address 


05 


Work as preferred c-mail address 








HOTEL PREFERENCES 




King-size bed 




Oueen-size bed 


CI 
J 1 


Double bed 




High lloor room 


Jj 


Low floor room 




Near elevaior room 




Away from elevator room 


36 






RENTAL CAR PREFERENCES 




Compact car 


ICQ 


Standard car 


101 


Mid-size car 


102 


Luxury car 


1 A** 

10^ 






AIRLINE PREFERENCES 




Window seat preferred 




Aisle seal preferred 


1 C 1 

151 


Low calorie 


152 


Vegetarian 


153 


Diabetic 


154 


Low sodium 


155 


Kosher 


156 



Table 38: Exemplary preference codes 



25 Security 

In the coniexi of smartcard transactions, data security has five primary 
dimensions: 1) data confidentiality. 2) data integrity, 3) access control, 4) 
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aiithemicaiion. and 5) non-repudiaiion. Each of these dimensions is addressed 
through a variety of security mechanisms. Data confidentiality, which deals with 
keeping information secret (i.e., unreadable to those without access to a key), is 
substantially ensured using encr>-ption technology. Data integrity (and data source 
5 verification) focuses on ensuring that data remains unchanged during transfer , and 
typically employs message authentication techniques. Access conirol involves card 
holder verification and other requirements necessary in order for a parly to read or 
update a particular file. Authentication involves ensuring that the caixJ and/or the 
external device is what it purports to be. and non-repudiation deals with the related 

10 task of ensuring that the source of the data or message is authentic, i.e., that a 
consumer may not repudiate a transaction by claiming that it was "signed" by an 
unaulliorized parly. 

Authentication is preferably performed using a "challenge/response" 
algorithm. In general, authentication through a challenge/response system involves: 

15 J ) generation of a random number by a first party; 2) transmission of the random 
number to a second pany (the "cliallenge'", 3) encryption of the random number by 
the second party in accordance with a key known to both parties. 4) transmission 
of the encrypted random number to the first party (the "response"), 5) encryption 
of the random number by the first party, and 6) comparison by the first parly of the 

20 two resulting numbers. In the case where the two numbers match, authentication is 
successfijl: if not, the authentication is unsuccessful. Note that authentication can 
work both ways: the external world might request authentication of a smartcard 
(internal authentication), and a smartcard might request authentication of the 
external world (external authentication), a more detailed account of a preferred 

25 challenge/response algorithm can be found in the IBM MFC specification. 

In a prefeired cmbodimem, the DES algorithm (Data Encryption Standard) 
is employed for the various security functions; however, it will be appreciated that 
any number of other symmetrical or asymmetrical techniques may be used in the 
context of the presem invention. More particularly, there are two general categories 

30 of encryption algorithms: symmetric and asymmetric. Symmetric algorithms use the 
same key for encryption and decryption, for example, DBA (data encrypUon 
algorithm) which uses a 56-bit key to encrypt 64-bit blocks of data. Asymmetric 
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algorithms, in con.rasi. use two diffcrem keys: one secret key and one public key. 
The RSA algorithm, for example, uses two such keys and exploits the 
computational complexity of factoring very large prime numbers. Additional 
information these and other crj'ptographic principles can be found in a number of 
5 standard texts, for example: Scbcrry & Pieprzyk, CRYPTOGRAPHY: AN 
INTRODUCTION TO COMPUTER SECURITY (1989); Rhee. CRYPTOGRAPHY AND 
SECURE COMMUNICATIONS (1994); Stinson, CRYPTOGRAPHY: THEORY AND 
PRACTICE ( 1 995); CONTEMPORARY CRYPTOGRAPHY: THE SCIENCE OF INFORMATION 

INTEGRITY (1992); and Schncier, APPLIED CRYPTOGRAPHY (2d ed. 1996). the 

1 0 contents of which arc hereby incorporated by reference. 

Access control is suitably provided by including access conditions vnihin the 
header of each EF and DF. Tliis prevents a particular operation (e.g.. reading or 
updating) from being pcrfomted on a file unless the required access conditions have 
been fulfilled. Many different access conditions are appropriate in a smart card 

15 context. For example, the smartcard might require cardholder verification (i.e., 
request that the cardholder enter a PIN) before a file operation is allowed. Similarly, 
internal and/or external authentication as described above might be required. 

Another important access condition (referred to herein as the SIGN condition) 
corresponds to the case where a particular file is "protected" and where updating of 

20 a record requires "signing" of ihe data using a message authentication code (MAC), 
a MAC can be thought of as a form of electronic seal used to authenticate the 
content of the message. In a paradigmatic signing procedure, a shortened, encrypted 
representation of tlie message (the MAC) is created using a message authentication 
algorithm (MAA) in conjunction with a key known to both the card and external 

25 dcvics;. The MAC is then appended onto the message and sent to the card (or 
exicmal device, depending on context), and the card itself generates a MAC based 
on the received message and the known key. Tlie card then compares the received 
MAC with the its own internally-generated MAC. If either the message or MAC 
was altered during transmission, or the sending party did not use the correct key, 

30 then the two MACs will not match, and the access condiUon will not be fiilfiUcd. 
If the two MACS conespond. then the access condition is fulfilled, and the 
particular file operation can proceed. 
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A MAC may be generated using a variety of MA As, for example, ihe ANSI 
X9.9 method using an eighi-byie key, or ihe ANSI X9. 1 9 method using a sixieen- 
byte key. Furthermore, the actual key may be "diversified" through encr>'piion with 
a random number or other appropriate value. These and other details regarding 
5 MAC generation can be found in the references cited above as well as the IBM 
MFC specification. 

Two other imponant access conditions are the NEVER and FREE conditions. 
The NEVER condition corresponds lo the case where a certain file operation 
(typically updating) is never allowed. The FREE condition, on the other hand, 

10 corresponds to the case where either updating or reading a file record is always 
allowed, without any additional preconditions for access. 

In contrast to the MAC techniques discussed briefly above, non-repudiation 
is necessarily performed using asymmetrical techniques. That is, as symmetrical 
techniques such as MAC "sealing" use a key known to more than one parly, such 

15 techniques can not be used by a third party to ascertain whether the source of the 
message is correct. Tlius, non-repudiation typically employs a public key encryption 
scheme (e.g., the Zimmemian's PGP system), wherein the sender uses a secret key 
to '^sign" the message, and the receiving party uses the corresponding public key to 
authenticate the signature. In the context of the present invention, this function is 

20 suitably performed by allocating an EF for public and secret key rings, which are 
well known in the an, along with suitable encryption software resident in the card 
for assembling the signed message. 

Having thus given a brief overview of typical smahcard security procedures, 
an exemplary set of access conditions is set forth below in Table 40. In this regard, 

25 the various access conditions for each EF arc tabulated with regard to whether the 
file is being read or updated. In each case, the access condition (FREE, SIGN, etc.), 
key '*owner" (issuer, partner, user, etc.), and key name are listed. In this regard, it 
will be appreciated thai the key name is arbitrary, and is listed here for the sake of 
completeness. 
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RF.ADINC 




UPDATING 






Access 

condiiion 


O^vncr 


Key 


Access 
condition 


Owner 1 


Key 


MF 

DF Cardholder ID 406 














DFHoldcrJD502 














EFID504 


FREf: 






SIGN 


ISSUER { 


KEY I 1 


EF Home 506 


FREE 






SIGN 


ISSUER 1 


KEYI 1 


EF Business SOS 


FREE 






SIGN 


ISSUER 1 


KEYI 1 


EF Preferences 514 


FREE 






SIGN 


ISSUER 1 


KEYI 1 


EF Passport 516 


FREE 






SIGN 


ISSUER 1 


KEY! J 


EF BiomcUics 522 


FREE 






SIGN 


ISSUER 1 


KEYI 1 


Driver 51 R 


FREE 






SIGN 


ISSUER 1 


KEYI 1 


DF Miscellaneous 














EFPaymcni card 510 


FREE 






SIGN 


ISSUER 1 


KEYI 1 


EF Sequence 512 


FREE 






FREE 






EF Card Number 526 


FREE 






SIGN 


ISSUER 


KEYI j 


DF Paymeni System 408 














DF 602 














EFPayl 604 


FREE 






FREE 






DF Airline 410 














DF Common 702 














EF Passenger 706 


FREE 






SIGN 


ISSUER 


1 KEY2 1 


EF Frequent nier 708 


l-REE 






SIGN 


ISSUER 


]kEY2 I 


. EFIET7I0 


FREE 






FREE 






EF Boarding 712 


FREE 






FREE 






EF Biomclric7l4 


FREE 






FREE 






DF Issuer 704 














EF Preferences 716 


FREE 






SIGN 


ISSUER 


j KEY2 1 


EF PfN7l8 


FREE 






SIGN 


ISSUER 


1 KEY2 1 


EF Issuance 720 


FREE 






SIGN 


icci tiro 


1 KEY2 


DF Rcnul car4l4 














DF Common 802 














EF Preferences 805 


FREE 






USER 


IDENT 


1 PIN 


DF Rcnial^car 803 
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i^m^^ninl cor ID S07 


FREI: 






SIGN 


RENTCAR 


KEY6 




FREE 






FREE 






PP P\n£nscs SI 1 


FREE 






SIGN 
(append) 
lOENT 
(erase) 


RENTCAR 
(append) 
USER 
(erase) 


KEY6 

(append) 

PIN 

(erase) 


DFHoicI system 412 




























ft* O imi OIK 


FREE 






FREE 






Er expenses 7 1 « 


FREE 






FREE 
(append) 
IDENT 
(erase) 


USER 
(erase) 


PIN 
(erase) 


EF Kcy-of-ihc-room 910 


FREE 






FREE 






EF Preferences 912 


FREE 






SIGN 


ISSUER 


KEYI 


DF HoicLchain 902 














EF Preferences 904 


FREE 






SIGN 


ISSUER 


KEYl 


EF Stayer ID 906 


FREE 






SIGN 


HOTEL 


KEYS 































Tabic 40: Exemplary access conditions 
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Transactions 

Having thus given a detailed description of an exemplary smaiicard 1 00 and 
a preferred data structure 400, the various details related to transactions involving 
smartcard 100 vnll now be described. In general, a typical smartcard session 
involves: (1) activation of the contacts (or comparable non-contact means); (2) card 
reset; (3) Answer to reset (ATR) by card; (4) Information exchange between card 
and host; and. at the conclusion of a session. (5) deactivation of contacts. 

First, card 1 00 is inserted in a card reader provided at an access point 1 5. and 
suitable connections are made between communication region 104 on card 100 and 
the card reader. In a preferred embodiment, physical contacts (contacts 106 in 
Fi-ure I) are used, and DATA. CLOCK, RESET. VDD. and GND connections are 
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made. These contacts are elecirically activated in a particular sequence, preferably 
in accordance with ISO 78)6-3 (RST to low slate, VDD powered, DATA to 
reception mode, then CLK applied). 

The card reader then initiates a reset (i.e., RST to high state), and the card 
5 returns an answer lo reset string (ATR) on the DATA line, preferably in 
conformance with the content and liming details specified in the appropriate parts 
of ISO 7816. In a preferred embodiment, the interface characters arc chosen to 
reflect a T=l protocol (asynchronous, half-duplex, block-oriented mode). Furtlier 
in accordance with JSO-7816-3, after the card sends an ATR siring and the proper 
10 protocol is selected (in a preferred embodiment, the T=l mode), host 314 and card 
100 begin the exchange of commands and responses that comprise a particular 
transaction. The nature of these commands is discussed in further detail below. 

At the end of a smartcard session, contacts 106 are deactivated. Deactivation 
of contacts 106 is preferably performed in the order specified in ISO 7816-3 (i.e., 
1 5 RST 10 low state, CLK to low state, DATA to low stale, VDD to inactive slate). As 
mentioned above, the VPP contact is not utilized in a preferred embodiment. 

In the context of the present invention, command classes and instructions are 
provided for 1) working with application data (i.e., files stored within the various 
applications), 2) ensuring data security, 3) card management, and 4) performing 
20 miscellaneous functions. 

Application data commands arc suitably directed at selecting, reading, and 
updating individual records or groups of records within files. Security commands 
suitably include commands for performing the challenge/response authentication 
process, generating random numbers, loading or updating cryptographic keys, and 
25 changing and verifying the card-holder verification codes (CH V I and CHV2). Card 
management commands suitably include commands which allow for the creation 
and deletion of directories (DFs) and elementary files (EFs). Miscellaneous 
commands are suitably provided for modifying the baud rate and reading various 
card statistics (e.g., data logged during production of the card.) It will be 
30 appreciated that many different command sets could be designed for implementing 
these basic functions. One such command set is provided by the IBM Multifunction 
Card Operating System 3.5 J, hereby incorporated by reference. 
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Referring again to Figure 10. access point 1 5 preferably comprises software 
which provides a user interface (for example, a graphical user interface) and is 
capable of executing the appropriate SCOS commands in accordance with the 
particular transaction being effected. For example, consider the case where a 
cardholder wishes to add a preference in car preferences EF 810 within rental car 
application 4 1 4 (shown in Figure 8). In this instance, a cardholder would locate a 
convenient access point 1 5 (for example, a stand-alone kiosk in a mall) and insert 
card 100 in a provided card reader in order to initiate a transaction. After suitable 
handshaking between card 100 and the card reader has taken place, and after the 
cardholder has been properly authenticated (i.e., the correct access conditions for 
updating car preferences EF 810 have been fulfilled), the application program at 
access point 15 queries the user with a choice of preference codes (for example, 
those listed in Tabic 39 above). The user then indicates a choice - through textual 
or graphical means, and the appropriate value is sent to card lOO by the application 
program as part of a command string. This value may then be sem to the appropriate 
partnering organization 12 (i.e., a rental car partner) and issuer 10 over network 19 
to be stored in their respective databases 13 and 1 1. Alternatively, this data may be 
sent later as part of a card/database synchronization procedure. c.g.. when the 
original transaction proceeds off-line. 

Consider, as another example, the typical hotel transaction. As detailed above, 
the cardholder inserts card 1 00 into a card reader deployed at a suitable access poim 
15. After appropriate initiaiiTation procedures take place, the cardholder is 
presented, through the use of a graphical user interface, the option to make a hotel 
reservation. Upon choosing this option, the software may interrogate the hotel 
preferences field in preferred programs EF 524 in cardholder ID application 406 and 
display these hotels first within the list of possible choices. 

After the cardholder selects a specific hotel property, the software conwcts the 
appropriate partner 12 over network 19 and requests a hotel room for a particular 
set of dates. This step might involve an interrogation of the various files within 
hotel system application 412 to which the particular hotel has access (i.e.. a hotel 
chain DF 902 or propert)' DF 903), or this step may be defened until check-in (as 
described below). 
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Once a reservaiion has been made, the associated confirmation number 
supplied by the hotel is downloaded into the confirmation number field in 
reservation EF 9J 8 along with the date and the property code of the hotel. This step 
mieht require the cardholder to transmit appropriate credit card information, which 
5 is suitably retrieved from payl EF 604. 

Upon arrival al the hotel, the cardholder may use smarlcard 100 to access a 
kiosk or other convenient access point provided for check-in. Thus, check-in may 
lake place unassisted by hotel personnel, or may involve a more traditional person- 
to-person interaction where card 100 is used primarily to streamline the check-in 

1 0 process initiated by personnel at the front desk. 

At check-in. the confirmation number information is retrieved from 
reservation EF 918.. and a particular room is assigned (if not assigned previously). 
This step will typically involve retrieving, from the appropriate preference file (i.e.. 
preferences EF 904 or 912); a list of preferences regarding bed size, room type, and 

15 the like. This list may be matched against the hotel's database of available rooms, 
thereby helping to streamline the room assignment process. 

Once a room is assigned, a digital key corresponding to the assigned room 
(e.g., a numeric value or alphanumeric string) may be stored in key-of-the-room EF 
9)0. Card readers are then employed as part of the door lock apparatus for each 

20 room> which are configured to open only upon receiving the correct key. 

At check-out time, payment may take place using payment card information 
stored in payment card EF 5 1 0 and payl EF 604. Again, a suitable smarlcard reader 
(i.e., an access point 15), may be provided in any location convenient for check out, 
e.g., the hotel lobby or within the individual hotel rooms themselves. Tlie 

25 cardholder may then acquire frequent stayer points, which would involve updating 
one of the stayer ID EFs 906 (or 936). During the course of his stay at the hotel, the 
cardholder may have incurred any number of expenses related to room-service, on- 
site dining, film viewing, and the like. These expenses, or a subset thereof, may be 
conveniently downloaded into expenses EF 916 for later retrieval, printout, or 

30 archiving. 

Use of card 100 in a rental car context would necessarily involve many of the 
same steps described above. The task of assigning a car would involve retrieving 
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car preferences stored within preferences EF 805 and comparins them lo a database 
of available automobiles. Upon returning the automobile, the cardholder might then 
be av.-ardcd frequent rental points (through update of frequent renter EF S07). and 
an expense record might be stored within expenses EF 811 . 

In the airline context, card 100 could be used lo make reservations, record, 
preferences, and provide a payment means as described above. In addition, 
electronic tickets may be downloaded (EF lET 710). and boarding information may 
be supplied via boarding EF 712. Frequent flyer EF 708 may then be used to update 
the cardholder's frequent flyer miles. 

While the example transactions set forth above are described in general terms, 
the particular nature of data flow to and from the appropriate memory locations 
within the card will be apparent to those i'cillcd in the art. 

Moreover, although the inventions set forth herein have been described in 
conjunction with the appended drawing figures, those skilled in the art will 
appreciate that the scope of ihc invention is not so limited. For example, although 
the preferred embodimem of the invention is discussed in the comext of a standard, 
credit card-sized smartcard with external contacts, it will be appreciated that 
virtually any portable memory device suitably configured may be utilized to 
practice this invemion, for example, contactless cards, optical cards, minicards, 
"super-smart" cards, and the like. Hence, various modifications in the design and 
arrangement of the components and steps discussed herein may be made without 
departing from the scope of the invention as set forth in the appended claims. 
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riaims 

1 1 . A smancard apparatus of the type configured to communicate with an external 

2 device to perform a transaction, said smancard apparatus comprising: 

3 «n smancard body; 

A an integrated circuit device disposed within said smancard body, said 

5 integrated circuit device comprising: 

6 (a) a cardholder identification application; 

7 (b) at least one second application for storing travel related 

8 information, said second application comprising a common 

9 file structure and at least one partner file structure; 

10 a communication means for providing data communication between said 

1 1 integrated circuit device and said external device; 



2. A smancard apparatus in accordance with claim 1, wherein said 
communication means comprises a plurality of external contacts disposed upon said 
smancard body. 



1 3. A smancard apparatus in accordance with claim 1, wherein said second 

2 application comprises: 

3 a payment system application; 
A an airline application; 

5 a hotel application; or 

6 a rental car application. 



4. A smancard apparatus of the.typc configured to communicate with an external 

device to perform a transaction, said smancard apparatus comprising: 
a smancard body; 

an integrated circuit device disposed within said smancard body and 
configured to communicate with said external device, said integrated 



*3 



circuit device comprising a common application and a second 
application, said second application being configured to store travel- 
related information associated with a cardholder; and 
communication means for providing data communication between said 
5 integrated circuit device and said external device. 

5. The smartcard apparatus of claim 4, wherein said communication means comprises 
a plurality of external contacts disposed on a surface of said smartcard body. 

6. The smartcard apparatus of claim 4, wherein said second application comprises a 
payment system application. 

10 7. The smartcard apparatus of claim 6, wherein said payment system application is 

configured to store an account number and an expiry date associated with a payment account. 

8. The smartcard apparatus of claim 4, wherein said second application comprises an 
airline application. 

9. The smartcard apparatus of claim 8, wherein said airline application is configured 
15 to store an electronic ticket. 

10. The smartcard apparatus of claim 4, wherein said second application comprises a 
hotel application. 

11. The smartcard apparatus of claim 10, wherein said hotel application is configured 
to store data associated with a hotel reservation. 
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12. The smartcard apparatus of claim 4, wherein said second application comprises a 
rental car application. 

13. The smartcard apparatus of claim 12. wherein said rental car application is 
configured to store data associated with a car preference. 

5 14. The smartcard apparatus of claim 4, wherein said common application comprises 

an £4)plication configured to store indicia of said cardholder's identity. 

15. The smartcard apparatus of claim 14, wherein said indicia of said cardholder's 
identity includes a name and an address. 

1 6. The smartcard apparatus of claim 4, wherem said common application provides 
1 0 general read access. 

1 7. The smartcard apparatus of claim 4, wherein said second application comprises a 
common file structure and a partner file structure, wherein said partner file structure provides 
write access to a field within said partner file structure for a first partnering organization and 
denies write access to said field for a second partnering organization, and said common file 

1 5 structure provides write access for both said first and second partners to at least one field in said 
common file structure. 

1 8. A smartcard apparatus of the type configured to communicate with an external 
device to perform a transaction, said smartcard apparatus comprising: 

a smartcard body; 

20 an integrated circuit device disposed within said smartcard body and 

configured to communicate with said external device^ said integrated 
circuit device including a cardholder ID application for storing 
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information related to a cardholder's identity, and a payment system 
application, said payment system application including fields for storing 
indicia of at least one credit account associated with a partnering organization; 
communication means for providing data communication between said 
integrated circuit device and said external device, 

1 9. The smartcard apparatus of claim 1 8, wherein said integrated circuit device further 
comprises an airline application, said airline application including a common airline file and a 
second airline file associated with a partnering organization. 

20. The smartcard apparatus of claim 1 8, wherein said integrated circuit device fiirther 
comprises a rental car application, said rental car application including a common car file and a 
second car file associated with a partnering organization. 

21. The smartcard apparatus of claim 19, wherein said integrated circuit device fiirther 
comprises a hotel application, said hotel application including a common hotel file and a second 
hotel file associated with a partnering organization. 

22. A distributed transaction comprising: 

a network for transmitting transaction information; 

a partnering organization having an associated partnering organization server, 
said partnering organization server being configured to send and receive 
said transaction information over said network; 

a smartcard access point, said smartcard access point being configured to 
interface with a smartcard and to accept user input, wherein said access 
point is fiirther configured to send and receive said transaction 
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information over said network in response to said user input, said 
smartcard comprising: 
a smartcard body; 

an integrated circuit device disposed within said smortcard 
body and configured to communicate with said smartcard 
access point, said integrated circuit device comprising a 
common application and a second application, said 
second application being configured to store travel- 
related infomiation associated with a cardholder; and 

communication means for providing data communication 
between said integrated circuit device and said smartcard 
access point. 
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